신입 개발자 온보딩 후기
박현우1. 간단한 소개
안녕하세요. 저는 이번에 팀스파르타에 신입개발자로 들어온 박현우 입니다. 지난 2주 가량의 온보딩 과정에 대해 후기를 공유해드리고자 합니다.
👊 온보딩 과정의 주제는
‘TDD 방법론을 사용해서 결제모듈을 개발하고, 이를 ECS 코드 파이프라인을 이용해서 배포하기’ 였습니다.2. TDD 과정의 느낀 점
우선, 첫번째로 개발을 시작한지 얼마 안되어 책에서만 보았던 ‘TDD(Test Driven Developement)’ 를 직접 해볼 수 있다는 점에서 상당히 즐거운 과정 이었습니다.
아무래도 처음 접하는 방법론이다 보니 책에서 배운 내용을 바로 적용하는 것이 쉽진 않았지만, 매일 오전 개발팀 리더님과 함께하는 온보딩 미팅을 통해 세세한 방향 조정을 할 수 있었습니다.
가령, 테스트 시나리오를 작성하는 과정에서 테스트 피라미드의 가장 아래부분인 ‘Unit Test’에 관해 듣지못했다면 전혀 독립적이지 않은 테스트 시나리오를 계속해서 작성하고 있었을 것입니다.
☝️ 테스트가 완전히 독립적이라는 건.
“문제가 하나면 테스트도 하나만 실패해야 하고, 문제가 둘이면 테스트도 두 개만 실패해야 한다."결제 정보 검증에 관한 테스트시나리오 중, “주문을 완료하는 함수” 를 테스트 하는 경우를 생각해보겠습니다.
주문을 완료하기 위해 필요한 게 무엇일까 생각하다보니,
- 주문 객체의 상태가 직전에는 ‘주문 요청’ 이어야 하고
- 주문 완료함수를 거치면서 주문 객체의 상태가 ‘주문 완료’ 로 바뀌어야 하며
- 주문이 완료됬다면 주문정보인 상품의 재고가 변경되어서 ‘마이너스 재고’현상이 일어나지 않도록 해야 할 것 같았습니다.
자연스러운 생각의 흐름이었지만 3번 시나리오는 테스트의 독립성을 헤치고 있었습니다.
왜냐하면, DB에 접근하고 해당 결과를 통해 테스트의 통과여부가 결정되기 때문입니다. 위의 테스트가 독립적이라는것의 의미에 비추어 보자면, 주문 객체의 상태가 변하지 않는 문제와 DB에 접근함으로써 발생하는 문제,** **두 가지문제에 의해 해당 테스트가 실패하게 됩니다. 즉, 테스트가 완전히 독립적이지 않다는 의미가 됩니다.
테스트가 독립적이지 않으면 테스트 순서에 따라 영향을 받을 수도 있고, 하나의 문제가 여러 테스트를 실패시키는 요인이 될 수 도 있습니다. 이는 실제 프로덕트를 테스트하는 과정에서 어떤 부분을 수정해야할지 파악을 어렵게 하고, 테스트 자체에 대한 신뢰도를 떨어뜨리는 결과로 이어집니다.
그렇기 때문에 이러한 독립적 테스트를 구성하고 코드를 작성하는 것이 중요함을 배울 수 있었습니다.
온보딩 과정에서 배운 TDD 방법론을 추후 실제 개발에 적용해보고, 독립적인 테스트가 주는 이점을 몸소 체험하는 것이 무척이나 기대가 됩니다.
3. ECS 를 이용한 배포 자동화 과정의 느낀 점
결제모듈을 만들고 난 다음에는 Amazon ECS 를 활용한 자동배포 CodePipeline 구축을 통해 처음 온보딩과정의 목표에 적혀있었던, ‘지식의 전달보다 중요한 사고방식의 교육’을 체감할 수 있었습니다.
Docker 를 1주차에 처음 사용해본 저에게 ECR, ECS 들은 많이 낯선 개념이었습니다. 뿐만아니라 Application Load Balancer, VPC, Fargate 등 온갖 처음보는 개념들이 등장했습니다. 이런 개념들은 각각을 깊게 공부하면 한 주제당 적어도 1주일은 사용할 수 있을 것들이었고 그러면 이번 과제를 마무리하는데까진 두달은 걸릴 것 이었습니다. (아래와 같은 예시 아키텍처를 완전히 이해하고 스스로 구성하려면 말입니다.)
그래서 마치 설명서를 읽듯이 파이프라인 구축에 관한 글을 읽어가며 한 단계씩 따라하기 시작했습니다. 아무것도 모르는 상태에서는 그대로 따라하기 조차 쉽지 않았습니다. 하지만 점차 익숙해져가며 조금씩 어떻게 해야하는 것인지 감을 잡기 시작했습니다. 그러다 자동배포 코드 파이프라인을 만들어냈을때, Git commit 이후 배포까지 자동으로 이루어지는 것을 보며, 아직 기술전환이 일어나지 않아 자동배포가 구성되어 있지 않은 도메인에 적용한다면 얼마나 편리해질까라는 생각과 함께 뿌듯함을 느꼈습니다.
처음 파이프라인 구성을 할때는 정말 막막했고 이에대해 아래와 같은 피드백을 받았습니다.
✌️ ‘실제 업무를 진행할 때에도 그런 느낌을 받을 때가 많다. 우리는 막막함에 익숙해질 필요가 있다.’저는 이 말이 온보딩 과정의 목표를 잘 설명해준다고 생각합니다. 막막하다는 것은 적어도 ‘무언가 시작했다’라는 말과 같습니다. 시작하지 않는 다면 막막함을 느낄 수 조차 없습니다.
이러한 막막함을 걷어내기 위해 자연스레 ‘우선순위’를 가지고 문제에 접근하게 됩니다. 눈앞의 문제들을 해결하기 위해 꼭 필요한 지식들이 무엇인지 파악하고, 이를 적용하여 해결합니다.
이는 팀스파르타의 핵심가치들, “빠르게, 와우하게, 진정성있게” 중 빠르게와 일맥상통합니다.
ECS 배포 파이프라인 구축 과정은 그 내용 자체로도 의미가 있었고, 온보딩의 목표와 맞닿아 있다는 점에서 더욱 의미있는 시간이었다고 생각합니다.
4. 마무리 소감
마지막으로 개인적인 소감을 말씀드리자면, 실제 팀에 투입되어 개발일을 시작하기 전에 온보딩 과정 속에서 스파르타의 팀 문화를 익힐수 있다는 것이 개인적으로 좋았습니다.
업무를 맡은 상태였다면 무언가를 물어볼때에도 스스로 부족한게 드러날까 걱정이 될 수도 있었겠지만 온보딩과정이라고 명시적으로 알려져있으니 다 아는 것이 기본이 아닌, 다 모르는 것이 기본이라는 마음가짐으로 거리낌없이 질문할 수 있었습니다.
뿐만 아니라 물어보는 것들에 진심으로 알려주고 싶어하는 표정으로 대답해주시는 팀원 분들을 보며 더욱 편하게 이야기 할수 있었습니다. 온보딩 기간 만난 여러 문제들에 고생하고 있을때 자기 일처럼 함께 고민해주신 여러 팀원분들에게 감사함과 앞으로 개발팀의 일원으로서, 열심히 한번 해보겠다는 각오를 전하며 글을 마치겠습니다.
감사합니다!